home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 93-10.Z / 93-10 / text0214.txt < prev    next >
Encoding:
Text File  |  1993-10-18  |  2.8 KB  |  64 lines
  1. Geoff Arnold @ Sun BOS - R.H. coast near the top writes:
  2. >
  3. >I believe that there was unanimity during the design meetings that a
  4. >successful call would _not_ modify the internal error variable accessed
  5. >via WSAGetLastError(). The intention was to mirror the semantics of the
  6. >Unix "errno" variable - indeed it is possible to #define errno as a
  7. >...
  8. >
  9. >     descriptions specify the details.  An error number  is  also
  10. >     made available in the external variable errno.  errno is not
  11. >     cleared on successful calls, so it  should  be  tested  only
  12. >     after an error has been indicated.
  13.  
  14. Picking a nit, but I think an important one.  The above says "...is not
  15. CLEARED...".  It does NOT say "...is not MODIFIED..."!  Maybe this isn't
  16. a problem with very-latest-wonder-Unices, but I've found to my great
  17. chagrin that one CANNOT rely on errno having ANY particular value after
  18. any successful library calls - and that includes value-as-of-last-error.
  19.  
  20. In other words, you not only can't rely on errno being cleared by
  21. successful calls, you also can't rely on it containing the last error
  22. which occurred, unless you test it IMMEDIATELY after the error occurred.
  23.  
  24. Fundamental defensive programming, really - if you need to look at the
  25. value of some external object over which you have no control, you'd
  26. better save your own copy as-of the snapshot of time for which you're
  27. interested in the value - don't assume it didn't change while you weren't
  28. looking.  Treat "extern" as "volatile".
  29.  
  30. -- 
  31. Carl Paukstis, RRR&RSG  Spokane, Washington, USA   carlp@mail.spk.olivetti.com
  32.  1KQSPI: 8.80  DoD#0432  Oli North: not responsible.  carlp@frigg.isc-br.com
  33. From rcq@ftp.com  Sat Oct 16 12:40:10 1993
  34. Received: from ftp.com by SunSITE.unc.edu (SMI4.1/FvK 1.02)
  35.           id AA04295; Sat, 16 Oct 93 12:40:10 EDT
  36. Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP
  37.     id AA29018; Sat, 16 Oct 93 12:40:21 -0400
  38. Date: Sat, 16 Oct 93 12:40:21 -0400
  39. Message-Id: <9310161640.AA29018@ftp.com>
  40. To: Geoff.Arnold@east.sun.com
  41. Subject: Re: WSAGetLastError() on success
  42. From: rcq@ftp.com  (Bob Quinn)
  43. Reply-To: rcq@ftp.com
  44. Cc: Multiple recipients of list <winsock@sunsite.unc.edu>
  45. Sender: rcq@ftp.com
  46. Repository: babyoil.ftp.com
  47. Originating-Client: oysters.ftp.com
  48.  
  49. >  >> the v1.1 specification does not explicitly say WSAGetLastError()
  50. >  >> can be used to indicate the success of the previous function.
  51. ...
  52. >  In other words, the successful
  53. >  function call would appear to have failed!
  54.  
  55. This was exactly the case that started this thread.  WSAGetLastError()
  56. returned an error after a successful call to accept().  The programmer
  57. thought our DLL was returning a bogus error.  Actually, we were returning
  58. a valid error from a previously failed WinSock function call.
  59.  
  60. --
  61.  Bob Quinn                                             rcq@ftp.com
  62.  FTP Software, Inc.                                No. Andover, MA
  63.  
  64.